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ABSTRACT 

Dynamic reconfiguration is the action of modifying a soft- 
ware system at runtime. Several works have been using ar- 
chitectural specification as the basis for dynamic reconfi- 
guration. Indeed ADLs (architecture description languages) 
let architects describe the elements that could be reconfig- 
ured as well as the set of constraints to which the system 
must conform during reconfiguration. In this work, we in- 
vestigate the ADL literature in order to illustrate how recon- 
figuration is supported in four well-known ADLs: 7T-ADL, 
ACME, C2SADL and Dynamic Wright. From this review, 
we conclude that none of these ADLs: (i) addresses the issue 
of consistently reconfiguring both instances and types; (ii) 
takes into account the behaviour of architectural elements 
during reconfiguration; and (iii) provides support for as- 
sessing reconfiguration, e.g., verifying the transition against 
properties. 

Categories and Subject Descriptors 

D.2 [Software]: Software Engineering 

Keywords 

dynamic reconfiguration, software architecture, architecture 
description language, ADL, 7T-ADL, ACME, C2SADL, Dy- 
namic Wright 

1. INTRODUCTION 
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The disciplined software engineering relies on software ar- 
chitectures to describe systems [3] . For modeling a software 
architecture, the academy proposed the architecture descrip- 
tion language (ADL) and their toolsets [lOl [181 ES]- Also, 
the industry has used ADLs to develop systems. Industry 
examples are (i) 7T-ADL has been used to architect and refine 
federated knowledge management systems in Engineering 
Ingegneria Informatica - Italy 22 ; (ii) and AADL (Archi- 
tecture Analysis & Design Language) is a standard language 
for the Society of Automotive Engineers [30]. According to 
the state-of-the-art [3]I18 | I19 | I29]. the following concepts are 
relevant to describe software architectures: components and 
connectors (respectively computational and communication 
elements), architectural constraints, non functional proper- 
ties, and behaviour. 

Software systems evolve over their life time 5, 21, 26 . Dy- 
namic reconfiguration is when the evolution is performed at 
runtime with no service disruption. The dynamic reconfigu- 
ration can be handled by architectural concepts in an ADL. 
However among many existing ADLs, only few allow model- 
ing dynamic reconfiguration. 7T-ADL [23], ACME/Plastik [4] 
[13] . C2SADL [16] [27], DAOP-ADL [28], Darwin [15], Dy- 
namic Wright [TJ[2], Rapide [32], Weaves [25], and xADL 
are typical examples. Nevertheless, there is no current con- 
sensus about how ADLs should address reconfiguration, e.g., 
what language constructs should be provided. 

In this work, the goal is twofold: (i) to investigate the ADLs 
support for handling dynamic reconfiguration in the litera- 
ture; and, (ii) to illustrate how four well-known ADLs sup- 
port dynamic reconfiguration: 7T-ADL, ACME, C2 SADL 
and Dynamic Wright. We chose these four languages be- 
cause they rely on different paradigms: the higher order 
typed 7r-calculus [23] . first order predicate logic [11], compo- 
nent- and event-based [311 116] . and, graph grammars and 
communicating sequential processes (CSP) [2] [TJ, respec- 
tively. They also complement each other as 7T-ADL models 
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Figure 1: simplified version of the TCP/IP stack 
system. 



the behavior of architectures, ACME focuses on the struc- 
ture, C2SADL make the attention for components and their 
concurrent events, and Dynamic Wright supports the defi- 
nition of structure and behavior. 

This work is structured as follows. Section [2] motivates this 
work thanks to the example of a TCP/IP stack system. 
Three scenarios illustrate three facets of dynamic recon- 
figuration. Section [3] presents the basics concepts of soft- 
ware architecture and dynamic reconfiguration. Section [4] 
details the related works about dynamic reconfiguration at 
the architecture level. Section [5] compares the four above- 
mentioned ADLs in the light of our example of Section [2] 
Section [6] concludes the paper with open issues that we note 
in the ADL support for dynamic reconfiguration. 

2. MOTIVATION 

Dynamic reconfiguration aims at modifying the software sys- 
tems at runtime with no service disruption. Critical systems 
usually want to benefit of a dynamic reconfiguration because 
any service disruption may have substantial consequences. 
Examples of critical systems are stock market quotation sys- 
tems, telecommunications systems, safety systems, and air 
traffic control systems. However, there is no current con- 
sensus about how the software architecture should address 
dynamic reconfiguration at architecture level. Does regular 
syntax for dynamic architectures allow the same reconfig- 
urations as specific language constructs? Should the state 
of components and connectors be taken into account at the 
architecture level? 

To support this work, we rely on a simplified version of the 
TCP/IP stack (Fig. |T(a)j ). Each of the four layers (Ap- 
plication, Transport, Internet, and Link) is modeled as a 
component (Fig. 1(b) I. 



Figure 2: scenario 1 to illustrate changing the com- 
ponent. 



We consider the three following reconfigurations: 

1. Switch the application component. Assume two alter- 
natives: MPEG-Decoder and H263-Deco der. M PEG- 
Decoder is used if bandwidth is high (Fig. |2(a)[ ). Oth- 
erwise H263-Decoder is selected (Fig 2(b) |. Switching 
between MPEG and H263 starts a new stream. There- 



Application 

ir 



Transport 




IPv4 




Link 



Legend: 
Component 




(a) IPv4 



(b) IPv6 replaces IPv4 



Figure 3: scenario 2 to illustrate insertion of com- 
ponent. 



fore, no state in the decoder needs be kept. We can 
therefore replace one component by another. 

2. Insertion of a new component type. Presume that the 
Internet Protocol version 6 (IPv6) replace the version 
4 (IPv4) (Fig. |3(b)| |. The IPv6 component has back- 
ward compatibility with the IPv4 component. So it 
has the ports for both IPv4 (for compatibility reason) 
and for IPv6 (new feature). Therefore, the type of the 
component at the internet layer is changed: it has 2 
additional ports. 

3. Update a component type. Assume that the algorithm 
of error control of the Transport component is im- 
proved. When the error control algorithm is changed, 
the new behaviour needs to know the status of each 
packet (acknowledged, sent, timeout, ...) as well as 
the content of non-acknowledged packets (in order to 
resend them). Therefore, only the behaviour part of 
the component should be replaced. The state of the 
component should be unchanged. 

These scenarios cover a wide spectrum. They can either be 
programmed at design-time or be discovered at run-time. 
They feature reconfiguration at both type and instance level. 



They target both the structure and the behaviour of the ar- 
chitecture. We investigate the ADLs literature in order to 
illustrate how reconfiguration is supported in these scenar- 
ios. 

In this paper, we focus on four ADLs that are representative 
of the main trends. Each ADLs complement the other. The 
complement at the sense for describing an initial architecture 
as well as dynamic reconfiguration. We choose 7T-ADL be- 
cause it provides both description with behaviours thanks to 
its 7r-calculus roots. Whilst the ACME/Plastik is a declar- 
ative language with focus on the architecture structure for 
both descriptions. While C2SADL is used to compose archi- 
tectures based on component and dynamic reconfiguration 
based on architectural events. Finally, Dynamic Wright pro- 
vides support for architectural description based in graph- 
grammars and dynamic reconfiguration specification with a 
variant of Communicating Sequential Processes (CSP). 

3. UNDERLYING CONCEPTS 

Software architecture concepts. Software architectures 
describe systems by specifying their elements and the in- 
teractions between them [3] [29]. In this work, we use the 
basics concepts defined in [101 1181 129] : a component is an 
unit of computation and storage; a connector is an unit of 
communication; and, a configuration is a specification of a 
software architecture in terms of components, connectors, 
and relationship between them. 

Ports, roles, behaviours, constraints, and non-functional pro- 
perties are other concepts defined in 10, 18, 29 used to de- 
scribe these architectural elements. Ports and roles are used 
to define the way of interaction, ports for configurations and 
components, and roles for connectors. Behaviours are the 
architectural element internal computation. And the last 
two concepts, constraints and non-functional properties, are 
used to denote the assertions, invariants, quality of service 
that architectural elements are expected to meet. 

Also, we consider types and instances of configurations, com- 
ponents, and connectors for modelling a software architec- 
tures |18l 129] . The types are abstractions like classes in 
the Object-Oriented Paradigm which encapsulate both the 
structure and the behaviours that can be performed on its 
structure. These types will be used to build the instances 
and these instances will be used to describe software archi- 
tectures. 

Fig. U illustrates in ACME the basics concepts with our ex- 
ample TCP/IP stack system (Sec. [2] Fig. [T(b)t at instance 
and type level. The types are defined in the Family state- 
ment block (lines 1-18) while the instance level in System 
(lines 20-30). 

Dynamic reconfiguration concepts. A dynamic reconfig- 
uration is a set of operations to modify an existing config- 
uration at runtime. At the software architecture level, the 
operation is defined in terms of the architectural elements 
at type or instance level. Scenario 1 is an example of recon- 
figuration at the instance level (MPEG and H263 share the 
same type); and scenario 2 is an example of reconfiguration 



i Family TCPIP_MF { 

Connector Type TCPIP_Conn2Layers { 

4 ProvidedRole source; 

5 RequiredRole sink; 
}; 

Component Type TCPIP_Component { 

Port Type DataFrom extends ProvidedPort with {}; 
Port Type DataTo extends RevidedPort with O; 
Property Type Layer = enumtapplication, transport, internet, 
link} 

11 }; 

L2 Component Type TCPIP_Application extends TCPIP_Component 
with { 

Port dataReceivedFromTransport: DataFrom; 

14 Port requiredService: DataTo; 

15 Property layer = "application" ; 

16 }; 

18 } 

19 

20 System DecoderStream : TCPIP_MF = new TCPIP_MF extended with { 

2 l Component application : TCPIP_Application; 

22 Component transport : TCPIP_Transpot ; 

2 3 Component internet : TCPIP_Internet; 
_' l Component link : TCPIP_Link; 

26 Connector 

application2transport, transport2internet, internet21ink: 
Conn2Layers ; 
Attchments { 

application. requiredService to application2transport. source; 
application2transport.sink to transport . service ; 

31 

32 transport. requiredService to transport2internet . source ; 

transport2internet.sink to internet . service ; 

34 

internet. requiredService to internet21ink. source; 

36 internet21ink.sink to link. service ; 

37 } 

38 ... 

30 } 



Figure 4: Simplified version of TCP/IP stack system 
in ACME ADL. 



at the type level (IPv6 extends the type of IPv4). 

Also, the dynamic reconfiguration can be foreseen or unfore- 
seen [12| . The foreseen is a programmed dynamic reconfig- 
uration specified at design time. While the unforeseen is an 
ad-doc defined at runtime. Example of foreseen and unfore- 
seen is the scenario 1 and 3, respectively. In the scenario 1, 
the architect specify at design time that the system modify 
itself when the bandwidth change. Whereas the behaviour 
improvement is built at runtime as defined in scenario 3. 

4. RELATED WORK 

Medvidovic and Taylor [18] created a classification frame- 
work based on architectural elements and illustrated them 
with the following ADLs: ACME, Aesop, C2, Darwin, Me- 
taH, Rapide, SADL, UniCon, Weaves, and Wright. How- 
ever, this work has no focus on the dynamic reconfiguration. 
Hence, its discussion about dynamic reconfigurations is lim- 
ited, e.g. all ADLs were assessed only at the instance level, 
not at the type level. 

Kacem et al. [14] described the capabilities of Darwin, Arch- 
Java, Olan, Rapide, Wright, and ACME to support dynamic 
reconfiguration. They classify the ADLs as configuration 
and description language. The configuration language sup- 



ports the description of a software system and limited dy- 
namic reconfigurations, while the description language sup- 
ports the specification of modifications to be applied to an 
existing architecture. Despite this work focus is on dynamic 
reconfiguration, it also presents some limitations such as the 
fact that the evolution is applied only at instance level and 
do not take into account the behaviour of the architectural 
elements. 

Bradbury 7 and Bradbury et al. [B] proposed a framework 
to compare fourteen formal specification approaches which 
support dynamic software architectures. Amongst the cri- 
teria, Bradbury et al. considered the basic operations, how 
they can be composed and whether they apply to variable 
sets of architectural element types. About the basic opera- 
tions (addition and removal of components and connectors), 
Bradbury et al. showed that most approaches support them. 
Also, they considered the criterion of operations composition 
(basicQ, sequence, choice, and iteration). Only 3 approaches 
(CommUnity, Dynamic Wright, and Gerel) provide full sup- 
port while the other only support basic composition. Finally, 
Bradury et al. mentioned that all approaches support only 
the types of architectural elements defined prior runtime, 
fixed sets of architectural elements. 

While ADL surveys have reached good understanding of the 
concepts underlying software architectures (Medvidovic and 
Taylor [18]), this is not true regarding dynamic reconfig- 
uration at the architecture level. Even Bradbury [7] and 
Bradbury et al. [6], probably the most complete surveys, 
do not consider operations such as insertion of configuration 
and behaviour modification. They do not recognize link and 
unlink as basic operations. However, they present the ex- 
amples of these operations on some approaches, like Gerel 
and C2SADL. Considering the scenarios of section [2] these 
related works address only the first scenario (partially) but 
not the two last. Consequently, it is clear that to discuss 
the three scenarios presented in section [2] is essential to have 
a better understanding of the dynamic reconfiguration is- 
sues. These scenarios consider both instance and type lev- 
els, the basic operations include configurations, components, 
and connectors, as well as their structures and behaviours. 

5. COMPARISON OF 4 ADL 
5.1 Applying the example in ADLs 

In this subsection, we describe the scenarios defined in Sec. [2] 
in all four ADLs: tt-ADL (subsection 15.1. ACME/Plas- 
tik (subsection I5.1.2JI . C2SADL (subsection 15.1.30 . and Dy- 
namic Wright (subsection 15.1.4)) . For each ADL we show 
the purpose, the TCP/IP stack system, a solution for three 
scenarios, and discussion about this implementation. 

5.1.1 n-ADL 

Purpose of the ADL. 7T-ADL is based on 7r-calculus and 
it is designed to describe the concurrent and mobile sys- 
tems [23]. The description of architectural elements is mainly 
represented by ports and behaviour. 



1 Basic composite operation is the ability to group basic op- 
erations for reconfigurations. 



Dynamic reconfiguration support. This ADL provides 
support for foreseen and unforeseen dynamic reconfigura- 
tion. The foreseen can be described in the behaviour of any 
architectural elements. While unforeseen needs some sup- 
port, e.g., in the Virtual Machine (VM), in order to obtain 
a root reference to the reconfigured system. In Arch Ware, 
this issue is addressed by the deep intrication between the 
toolset (including the visual and textual editors) and the 
VM thanks to the hyper-code technology |24j . 

Initial architecture. The implementation of TCP/IP stack 
system is shown in Fig. [5] The configuration is composed at 
lines 1-18 basically with a behaviour, statement behaviour 
is ... where ...! (lines 2-17). This architectural behaviour 
defines the instances of components (lines 3-6) and connec- 
tors (lines 7-9). The statement where in behaviour specifies 
the connections between components and connectors (lines 
11-16). The example of component TCPIP_Application is 
partially showed at lines 20-35: two ports and a behaviour. 
The component behaviour is implemented with two internal 
methods (lines 24-25) and the definition of communication 
between its ports (lines 27-33). 



Scenario 1. The implementation of scenario 1 in 7T-ADL is 
composed by a component that performs the dynamic re- 
configuration (Fig.[B]). This component has two parameters: 
the application component and the system component. Both 
are represented as a behaviour. The application component 
is a MPEG-Decoder or H263-Decoder. 

Still, this component is structured with seven "variables" and 
a behaviour, lines 2-4 and 5-27, respectively. The variables 
are used for behaviours of components and connectors. To 
perform the modification, the behaviour component use the 
following steps: decomposition the system behaviour (line 
6); assign the behaviours to variables (lines 8-14); compose 
a new system behaviour (lines 16-26) with a replaced appli- 
cation component (line 20). 

Scenario 2. The implementation for the unforeseen sce- 
nario 2 is shown in Fig. [7] This code is applied in a system at 
runtime to deploy the two new component "type". First, the 
component type is a new protocol IPv6 (lines 1-3), and the 
second is a component to perform dynamic reconfiguration 
(lines 4-32). In order to execute this dynamic reconfigura- 
tion two steps are applied: (i) to obtain the root behaviour 
of the system, and (ii) to invoke the computation of the 
reconfiguration component. Both operations are aided by 
toolset and hyper-code. 

The code of the reconfiguration component is described us- 
ing the following steps: (i) to decompose the behaviours 



decomposition, modification, and composition is a process 
provided by the ArchWare Virtual Machine. This facility is 
possible: take a snapshot of the system or a specific com- 
ponent/connector, both represented as a sequence of be- 
haviour; make a modification; and, compose again the be- 
haviour with new composition. When it is composed, the 
ArchWare Virtual Machine automatically updates the sys- 
tem. 



1 archictecture TCPIP is abstraction { 

2 behaviour is compose { 

3 application is TCPIP_Application() 
and transport is TCPIP_Transport ( ) 

5 and net is TCPIP_Internet() 

6 and link is TCPIP_Link() 
and app2transp is Conn2Layers() 
and transp2net is Conn2Layers() 
and net21ink is Conn2Layers() 

10 } where { 

appliation: :request unifies app2transp: :source 

and app2transp: :sink unifies transport: :service 
13 and transpost :: request unifies transp2net: : source 

and transp2net: :sink unifies net: :service 
15 and net: :request unifies net21ink: :source 

and net21ink: :sink unifies link: :service 

17 } 

18 > 

19 

component TCPIP_Application is abstraction () { 

21 port service is { ... >. 

22 port request is { ... >. 

23 behaviour is { 

processRequest is function (d: DataType) :DataType { 
unobservable} . 
25 processResponse is function (d:DataType) :DataType { 

unobservable} . 

26 

27 choose { 

via service: :wait receive entryData: DataType. 
via request: :call send processRequest (entryData) . 

30 or 

via request: :response receive replyData: DataType. 

32 via service: :reply send processResponse (replyData) . 

33 } 

34 > 

35 > 

36 

component TCPIP_Transport is abstraction () { . . . } 



38 

39 component TCP IP_ Internet is abstraction () { . . . } 

40 

component TCPIP_Link is abstraction () { ... } 

42 

i . connector Conn2Layers is abstraction () { 



44 

45 port source is { ... } 
port sink is { ... > 

47 

48 behaviour is { ... > 



49 } 

Figure 5: Partial specification of the TCP/IP stack 
system in 7T-ADL. 



of the system in components and connectors (lines 9); (ii) 
to assign to "variables" the instances of components that 
represent application, transport, and link (lines 11-13); (iii) 
to attribute connectors to "variables" (lines 15-17); (iv) to 
compose a new system behaviour (lines 19-30) with a new 
instance of the protocol IPv6 component (line 21). As in 
the scenario 1, when performing a new composition, the be- 
haviour of the system is automatically updated. 

Scenario 3. In the scenario 3 it is also used the process 
of decomposition, modification, and composition, as showed 
above. We use the Arch Ware Virtual Machine facility to get 
a reference to the root of the target Transport component. 
After, we make a modification into the behaviour of the com- 
ponent. At last, the Arch Ware Virtual Machine synchronize 
the system with this modification. 



component reconfiguration is abstraction (application: 



Behaviour, system: Behaviour) { 
behaviours : sequence [Behaviour] . 
3 transport : Behaviour, net : Behaviour, link : Behaviour. 

app2transp : Behaviour. transp2net : Behaviour. net21ink : 
Behaviour. 

5 behaviour is { 

6 behaviours := decompose system. 
7 

8 transport : = behaviours : : 1 : : bhvr . 

9 net := behaviours: :2: :bhvr. 
10 link := behaviours: :3: :bhvr. 

n 

12 app2transp := behaviours: :4: :bhvr. 

transp2net := behaviours: :5: :bhvr. 
14 net21ink := behaviours: :6: :bhvr. 

15 

16 compose { 

17 application and transport and net and link 
and app2transp and transp2net and net21ink 

19 } where { 

appliation: :request unifies app2transp: :source 
and app2transp: :sink unifies transport: :service 
and transpost: :request unifies transp2net: :source 

23 and transp2net: :sink unifies net: : service 

and net: :request unifies net21ink: :source 

25 and net21ink: :sink unifies link: :service 

26 } 

27 } 



28 } 

Figure 6: Implementation of scenario 1 in 7T-ADL. 

Summary of tv-ADL. With these implementations, some 
issues are identified on tt-ADL support for dynamic recon- 
figuration: 

1. changing types needs external help, e.g. toolset, hyper- 
code and 7T-ARL. Toolset and hyper-code are used for 
capturing, specifying the changes, and applying the 
changes. While 7T-ARL is a language to specify refine- 
ments in the system; 

2. instances modifications can be specified in architec- 
tural elements or also with toolset and hyper-code help. 
At first, usually the dynamic reconfiguration is tangled 
with nominally behaviour. However, we used other ap- 
proach with a specific component to specify dynamic 
reconfiguration; 

3. For the third scenario, the 7T-ADL do not provide a 
mechanism to design the intermediate states for updat- 
ing the instances with the improvement of behaviour. 
However, if we use the tt-ARL approach, we can have 
better control; 

4. Also with 7T-ARL is possible build constraints and non- 
functional properties for architectural elements. How- 
ever, it's not used to assess dynamic reconfiguration. 

5.1.2 ACME ADL and Plastik 

Purpose of the ADL. ACME/ Armani is a declarative lan- 
guage based on the first-order predicate logic [20] . Its 
initial purpose was to define a common interchange lan- 
guage for architecture design tools. Also, its statements 
are designed to describe the architectural structures at in- 
stance and type levels. The extensions [4j [13] to support dy- 
namic reconfiguration preserves these initials purpose, and 



component TCPIP_IPv6 is abstracionO { 

2 

3 } 

i component reconfiguration is abstraction (system: Behaviour) 



{ 

behaviours : sequence [Behaviour] . 

application: Behaviour, transport : Behaviour, link : 
Behaviour. 

app2transp : Behaviour. transp2net : Behaviour. net21ink : 
Behaviour, 
s behaviour is { 

9 behaviours := decompose system. 

10 

application := behaviours: :0: :bhvr. 
transport := behaviours: :1: :bhvr. 
13 link := behaviours: :3: :bhvr. 

14 

15 app2transp := behaviours: :4: :bhvr. 

transp2net : = behaviours : : 5 : : bhvr . 
17 net21ink := behaviours: :6: :bhvr. 

is 

19 compose { 

application and transport and link 

21 and net is TCPIP_v6 

and app2transp and transp2net and net21ink 

23 } where { 

appliation: :request unifies app2transp: :source 
and app2transp: :sink unifies transport: :service 
and transpost: :request unifies transp2net: :source 

27 and transp2net: :sink unifies net: :service 

and net: :request unifies net21ink: :source 

and net21ink: :sink unifies link: :service 

30 } 

31 } 



32 } 

Figure 7: Implementation of scenario 2 in tt-ADL. 



are named as ACME/Plastik. Thereafter, any configuration 
and dynamic reconfiguration specified using this extension 
(ACME/Plastik) are based on the structure of an architec- 
ture. 



Dynamic reconfiguration support. ACME/Plastik per- 
mits to describe foreseen and unforeseen dynamic recon- 
figuration. To unforeseen reconfiguration it is possible to 
describe as a specific behaviour of a configuration with the 
on (conditional _expression) do {operations'} statement. 
Unforeseen reconfiguration can be expressed in a script that 
will be applied in the system at runtime aided by a toolset 
provided by the Plastik framework. Both, operations and 
script are composed with ACME statements and its ACME/- 
Plastik extension. The conditional_expression is composed 
in the Armani language |20j . 

Initial architecture. The example of the TCP/IP stack 
system in ACME is showed in Fig. [4] The types are spec- 
ified in the Family statement while the instances are in 
the System statement. For types, a connector (lines 3-6) 
and two components (lines 7-11 and 12-16) are implemented 
as example. The configuration is composed by the compo- 
nent instances (lines 21-24), connector instances (lines 26- 
27), and the connections between them (lines 28-37). 



Scenario 1. The implementation in ACME/Plastik of sce- 
nario 1 is showed in Fig. [8] The configuration is named 



i System StreamDecoderSystem : TCPIP_MF, PlastikMF { 
Component mpeg-decoder : TCPIP_MpegDecoder = new 
TCPIP_Application extend with { 
3 property decodeiH:ype = "MPEG" ; 

property algorithm = . . . ; 

} 

Component h263-decoder : TCPIP_H263Decoder = new 
TCPIP_Application extend with { . . . > 
7 // other instances of component and connector 

s 

// initial attachments 

10 

n //programmed dynamic reconfiguration to low bandwidth 
12 on Clink. bandwidth == 'low') do { 

detach mpeg-decoder. requiredService to application2transport. 
source ; 

detach transport2application.sink to mpeg-decoder. 
dataReceivedFromTransport; 
15 attachments { 

h263-decoder . requiredService to application2transport. source 

17 transport2application.sink to h263-decoder . 

dataReceivedFromTransport ; 

is } 

19 } 

20 //programmed dynamic reconfiguration to high bandwidth 

on Clink. bandwidth == 'high') do { 

detach h263-decoder . dataTo to application2transport. source; 
detach transport2application.sink to h263-decoder . 
dataReceivedFromTransport ; 

24 attachments { 

25 mpeg-decoder. requiredService to application2transport. source 

26 transport2application.sink to mpeg-decoder. 

dataReceivedFromTransport ; 

27 } 

2S } 
29 } 



Figure 8: Implementation of scenario 1 in ACME/- 
Plastik. 



with StreamDecoderSystem and it extends the TCPIP_MF 
and PlastikMF. The TCPIP_MF is showed in Fig. Q] while 
Plastik_MF in [4] [13]. Such configuration consists of: the 
insertion of two new components (type and instance) in lines 
2-5 and line 6; the instantiation of components and connec- 
tors (omitted with comment and ... in lines 7-8); the linking 
of components and connectors (omitted with comment and 
...in lines 7-8); and the specification of two dynamic recon- 
figuration situations, lines 12-19 and 21-28. 

Both dynamic reconfigurations use the same similar descrip- 
tion. First, the conditional expressions are link. bandwidth 
== 'low' and link. bandwidth == 'high'. Second, the 
operations are described as two unlinking (lines 13-14, 22- 
23) and one linking (lines 15-18, 24-27) statements. These 
operations specified the replacement of an instance of the 
component. 

Scenario 2. The scenario 2, an unforeseen insertion of a 
new component type, is describe with an ACME/Plastik 
script in Fig. [9] For this scenario, the script is composed by: 
the insertion of a type and instance of a component (lines 
1-3), the unlinking of the old component instance (lines 5-6) 
and the linking of the new component (lines 7-10). 



1 Component ipv6 : TCPIP_IPv6 = new TCPIP_ Internet extended 

with { 

2 ... 

3 } 

4 

detach ipv4.requiredService to internet21ink. source; 
detach link2internet . sink to ipv4.dataReceivedFromLink; 
7 attachments { 

ipv6.requiredServi.ce to internet21ink. source; 
9 link2internet.sink to ipv6.dataReceivedFromLink; 
in } 



Figure 9: Implementation of scenario 2 in ACME/- 
Plastik 

Component Type TCPIP_Transport extends TCPIP_Component with { 

Property behaviour = { 

\\ description of behaviour in other languages, e.g. CSP 

} 

6 

V } 

Figure 10: Implementation of scenario 3 in ACME/- 
Plastik 

Scenario 3. The unforeseen upgrade of a behaviour in sce- 
nario 3 can be described by the script illustrated in Fig. 1101 
This script defines a new version of a component with an im- 
provement on its behaviour. The behaviour in ACME/Plas- 
tik is expressed as a property and it can be also described in 
other languages, such as external formal languages, see lines 
3-5 in Fig. [TO] 

Summary of ACME/Plastik. The dynamic reconfiguration 
issues for ACME can be summarized as follows: 

1. Dynamic reconfiguration in terms of structure is sup- 
ported by ACME/Plastik. In terms of behaviour, dy- 
namic reconfiguration is described using any external 
language embedded inside the property element. Usu- 
ally, this is used for foreseen reconfiguration. This ap- 
proach is limited in the sense that components and 
connectors usually needs the dynamic reconfiguration 
of their behaviour but as ACME/Plastik does not pro- 
vides elements for behaviour specification, the archi- 
tect has to rely on an external language. E.g. if the 
TCPIP_Transport component needs to decide if it has 
a buffer or not, and if it uses a error detecting or not, 
and so on. These situations have to be described using 
an external language (in general formal languages such 
as CSP). 

2. ACME/Plastik does not provide a mechanism to con- 
trol the intermediate states of a reconfiguration. E.g. 
the implementation of the scenario 3, the architect can- 
not define the approach used to update the instances. 

3. For unforeseen reconfiguration ACME/Plastik relies 
on external scripts. This approach requires an exter- 
nal interpreted associated to the ADL to interpret the 
external script in order to reconfigure the system. 

5.1.3 C2SADL 



component TCPIP_Transport is 

interface // define the component ports 

top_domain is //ports to link high level connectors 

5 OUt 

6 

7 in 

8 ReceiveDataCpackage: ApplicationPackage) ; 
bottom-domain is //ports to link low level connectors 

10 out 

SendToInternt (package : TransportPackage) ; 

12 in 

13 

methods // define interfaces of internal behaviours 
15 function pack(data: ApplicationPackage) : TransportPackage 

); 

16 

behaviour // describe the external behaviour 

18 

19 received_messages ReceiveData; 

20 invokejnethods Pack; 

21 always_genarate SendTo Internet ; 

22 ... 

23 end TCPIP_Transport 

24 



Figure 11: Components of TCP-IP stack system def- 
inition in C2 IDL. 



Purpose of the ADL. Initially, the purpose of C2 was to 
describe the architecture of a software based on a Graphical 
User Interface (GUI) [31]. Therefore, the ADL is based on 
hierarchically concurrent components. C2 also allows the 
use of messages to notify the architectural elements. C2 
is subdivided in 2 languages: C2 IDL (Interface Descrip- 
tion Language) for describing the components types, and 
C2 ADL to specify the configurations. For components it 
is possible to specify top and bottom ports, to declare in- 
ternal methods, and to specify the behaviour of its ports. 
The implementation of the internal methods is done by the 
developer in the source code generated by a toolset. With 
C2 ADL it is possible to define instances of components and 
connectors, as well as links between them. 

Dynamic reconfiguration support. The Architectural 
Modification Language (AML) was created to extend C2 
for supporting dynamic reconfiguration |16l 127] . AML is a 
declarative language that uses the structure view of an exist- 
ing configuration and messages to notify this configuration 
about a dynamic reconfiguration. This language provides 
statements to build the scripts that specify dynamic recon- 
figuration. However, in these scripts it is not possible to 
determine the moment to apply a dynamic reconfiguration. 
Because that, human intervention is needed via a toolset to 
trigger dynamic reconfiguration. 

Initial architecture. The TCP/IP stack system is descri- 
bed in C2 IDL in Fig. [11] and C2 ADL in Fig. \U\ 



Scenario 1. For scenario 1, for changing the component 
according to the low or high bandwidth state, it is nec- 
essary two C2SADL scripts. In Fig. [13] is described the 
script for dynamic reconfiguration when bandwidth is low. 
This script uses two statements, a Unweld for unlinking 



1 architecture DecoderStream is 

2 component _intances { 

3 mpeg instantiates TCPIP_MpegDecoder; 
h263 instantiates TCPIP_H263Decoder; 
transport instantiates TCPIP_Transport ; 

6 internet instantiates TCPIP_Internet; 

7 link instantiates TCPIP_Ltnk; 

8 } 

9 connectors { 

application2transport; 

1 1 transport 2 internet ; 

12 internet21ink; 

13 } 

14 topology { 

is connector application2transport { 

top_ports { mpeg filter no_f iltering; } 

17 bottom_ports { transport filter no_f iltering; > 

18 } 

19 connector transport 2 internet { 

top_ports { transport filter no_f iltering; } 
bottom_ports { internet filter no_f iltering; > 

22 } 

connector internet21ink { 

top_ports { internet filter no_f iltering; } 
bottom_ports { link filter no_f iltering; } 

26 } 

27 } 

28 end DecoderStream; 



Figure 12: TCP-IP stack system implementation in 
C2 ADL. 



\\ Creata a new type of component 
2 component TCPIP_IPv6 is subtype 
all <= all TCPIP_Internet (...) 

4 

end TCPIP_IPv6 

6 

7 // Create a new instance of component 

// The name of the type is implicitly discovered 
DecoderStream.AddCbnponent(TCPIP_IPv61) ; 

10 

// Unlink the instance of component IPv4. 

12 DecoderStream.Unweld(trasport2internet, TCPIP_IPv41) ; 

13 DecoderStream.Unweld(TCPIP_IPv41, internet21ink) ; 

14 

L5 //Link the instance of component IPv6 

Li DecoderStream.Weld(trasport2internet, TCPIP_IPv61) ; 

L7 DecoderStream.Weld(TCPIP_IPv61, internet21ink) ; 



Figure 14: Implementation of scenario 2 in 
C2SADL. 

1 component TCPIP_Transport is 

2 

behaviour // describe the external behaviour 

4 

5 received_messages ReceiveData; 

invoke_methods VerifyData, Pack; 

7 always_genarate SendToInternet ; 

8 ... 

end TCPIP_Transport 



1 \\ Bandwidth is low 

2 DecoderStream. UnweldCmpeg, application2transport) ; 
DecoderStream.We]d(h263, application2transport) ; 



Figure 13: Partial implementation of scenario 1 in 
C2SADL. 



the mpeg instance and Weld for linking the /i263 instance. 
Other AML's statements are AddComponent , AddConnector, 
RemoveComponent , and RemoveConnector. All these state- 
ments are used with a defined configuration, e.g. line 2 and 
3 in Fig.[l3]with the configuration named as DecoderStream. 
Despite of the fact that AML statements are based on ser- 
vices of the ArchStudio tool suite, there are services that 
are not provided by the AML language, e.g. start () and 
stopO . 



Scenario 2. The second scenario, the unforeseen insertion 
of component instance and type, is inferred as shown in 
Fig. [TU Inference because both work about AML pU [27] 
stated that it is possible to make insertion and deletion of 
types. However, they only show examples how to build dy- 
namic reconfiguration at the instance level. Medvidovic et 
al. [17] mention types and subtypes but at design level. 

Dynamic reconfiguration in Fig. [14] specifies: the insertion 
of a new type of component (lines 2-5), the creation a new 
instance of component (line 9), the unlinking of the instance 
of IPv4 (lines 12-13), and the linking of the instance of IPv6 
(lines 16-17). The component type name is inferred by a 
toolset before performing dynamic reconfiguration. 



Figure 15: Implementation of scenario 3 in 
C2SADL. 

Scenario 3. The third scenario is an improvement of the 
behaviour that can be modeled by the behaviour statement 
via a sequence of invocations to internal methods. Example 
of this change, see line 6 in Fig. 1151 the invocation is mod- 
ified to verify the received and packed data before sending 
a transport package to the internet layer. If the change is 
an improvement of an internal method, it is not possible to 
describe with C2SADL. 



Summary of C2SADL. After the C2SADL implementa- 
tion of the three scenarios, we identified these issues: 

1. ArchStudio tool provides some services for supporting 
dynamic reconfiguration, e.g. to start and to stop ar- 
chitectural elements. However, these services are not 
available in AML. Thus, the dynamic reconfiguration 
specification in AML is limited. 

2. foreseen dynamic reconfiguration needs human inter- 
vention because C2SADL do not provide statements 
for the system apply dynamic reconfiguration. 

3. it does not support the specification of dynamic recon- 
figuration inside of the architectural elements. Because 
that, the foreseen dynamic reconfiguration is imple- 
mented only at the implementation level; 

4. it does not provide a mechanism for controlling and 
monitoring the intermediate states of a dynamic re- 
configuration; 



5. it also does not support the assessment of dynamic 
reconfiguration. 

5.1.4 Dynamic Wright 

Purpose of the ADL. Dynamic Wright has focus on the 
structure and behaviour of an architecture 2 . Dynamic 
Wright supports the description of the architectural ele- 
ments types structures and behaviourfl and initial configu- 
ration. Structure, initial configuration, instances, and links 
are described in a declarative form, while behaviours are 
specified in a graph-based and a variant of the Communi- 
cating Sequential Process (CSP) form. 

Dynamic reconfiguration support. Dynamic Wright only 
supports foreseen dynamic reconfiguration. It is built as a 
special behaviour of the initial configuration. It has the 
same base of a "nominally" behaviour of architectural ele- 
ments. The extension described in [2] proposes additional 
statements and control events. The statements are new, 
remove, attach, and detach. The control events are used 
to define the specific moment to perform a dynamic recon- 
figuration. 

As Dynamic Wright does not support unforeseen reconfigu- 
ration, the scenarios 2 and 3 cannot be implemented. 



Initial architecture. The initial configuration of the TCP /- 
IP stack system is illustrated in Fig. 1161 The component and 
connector types are specified in the Style . . . EndStyle 
(lines 1-16) statements. The implementation of the TCPIP_ 
MPEG— Decoder Component is described with two ports (lines 
3-4) and a behaviour (lines 6-7). The configuration is de- 
scribed with the Configuror ... EndConf iguror statement. 
The initial configuration instances and connections are spec- 
ified at lines 18-27. 



Scenario 1. Fig. [16] also illustrates the specification of sce- 
nario 1. It uses the Configuror [initial configuration 
Jwhere [behaviours] Statement, behaviours axe special 
named behaviours of the configuration for specifying dy- 
namic reconfiguration. In this case, there are two specifi- 
cation: lines 29-36 for low bandwidth and lines 37-44 for 
high bandwidth. The following steps were used to define 
the first and the second dynamic reconfiguration situations: 



1 Style TCPIP-Style 

2 Component TCPIP_MPEG-Decoder 

Port dataReceivedFromTransport = . . . 
4 Port requiredService = . . . 

[describe the port behaviour using a variant of CSP] 

6 Computation = . . . 

7 [describe the component behaviour using a variant of CSP] 

8 • • ■ 

Connector Conn2Layers 

10 Pole source = . . . 

11 Pole sink = . . . 

12 Glue = . . . 

13 [describe the connector behaviour using a variant of CSP] 

14 Constraints 

16 EndStyle 

1 7 Configuror DecoderStream 

18 Style TCPIP-Style 

19 new.mpeg : TCPIP_MPE(M)ecoder 

20 — > new.h263 : TCPIP_H263-Decoder 

21 ... [other component instances] 

22 — f new. app2trans : Comi2Layers 

23 — ¥ new.trans2net : Conn2Layers 

24 — > new.net21ink : Conn2Layers 

— > attach .mpeg. requiredService . to . app2trans . source 
— > attach .app2trans . sink, to .transport . service 

27 ... [other attachments] 

28 where 

29 WaitForBandwidthLow = C 

link. control. bandwidthDown — > mpeg. control. of f — > h263. control 
.on 

31 Style TCPIP-Style 

detach .mpeg. requiredService . to . app2trans . source 

33 — >- attach. h263. requiredService. to. app2trans. source 

34 — f detach. trans2app. sink. to. mpeg. dataReceivedFromTransport 

35 — > attach. trans2app. sink. to. h263. dataReceivedFromTransport 

36 ) □ § 

37 WaitForBandwidthHigh = C 

38 link. control. bandwidthUp — V h263. control. of f — > — > mpeg. 

control . on 

39 -> Style TCPIP-Style 

detach .h263 . requiredService . to .app2trans . source 
— > attach .mpeg. requiredService . to . app2trans . source 
— > detach. trans2app. sink. to. h263. 

dataReceivedFromTransport 
— > attach. trans2app. sink. to. mpeg. 

dataReceivedFromTransport 

44 ) □ § 

: EndConfiguror 



Figure 16: Implementation of scenario 1 in Dynamic 
Wright 



4. to specify the operations to perform dynamic reconfig- 
uration (lines 32-35 and 40-43). 

5. to use the statements of the external choice (□) and 
successfully terminate (§), lines 36 and 44. 



1. to define a name (lines 29 and 37). 

2. to specify the control events that define the moment for 
performing the operations of dynamic reconfiguration 
(lines 30 and 38). 

3. to determine the type of configuration to use (lines 31 
and 39). Dynamic Wright use the term Style for this 
purpose. 

3 In Dynamic Wright it is possible to specify the behaviour 
for component ports and computations, and connector roles 
and glues. 



Summary of Dynamic Wright. The following issues are 
identified after the implementation of the scenario 1: 

1. it does not provide operations to define dynamic recon- 
figuration for the type level of architectural elements; 

2. this ADL provides a refined mechanism of control e- 
vents to determine the moment to perform a dynamic 
reconfiguration. Although, it does not provide a mech- 
anism to control and monitor the intermediate states, 
e.g. if the application of the scenario 1 is a banking sys- 
tem, the state must be copied from the instance of the 



Table 1: Foreseen and unforeseen dynamic reconfig- 
uration support in ADLs. 



Table 2: Dynamic reconfiguration support for mod- 
ification on type and instance level. 





Foreseen 


Unforeseen 


7T-ADL 


inside of all archi- 
tectural elements be- 
haviour 


ADL statements aided 
by the Arch Ware 
toolset 


ACME 
Plastik 


special behaviours in 
the configuration 


ADL statements and 
external language 
aided by the Plastik 
framework 


C2SADL 


limited support by the 
ADL 


external script in AML 


Dynamic 
Wright 


special behaviours in 
the configuration 


not provided by the 
ADL 



replaced component to the new component. Dynamic 
Wright does not provide operations for this purpose. 

3. despite of providing the specification of behaviour for 
components and connectors, it is not possible to de- 
fine dynamic reconfiguration for this architectural ele- 
ments; 

4. similarly to the other ADLs, Dynamic Wright does not 
provide a mechanism for the assessment of dynamic 
reconfiguration. 

5.2 Summary of comparison 

The summary of the four ADLs support for dynamic recon- 
figurations is shown in Tab. [T] 7T-ADL and ACME/Plastik 
are the only ADLs that support both foreseen and unfore- 
seen dynamic reconfigurations. As C2SADL with the AML 
language do not provide a way to specify an internal initia- 
tion of dynamic reconfiguration, foreseen dynamic reconfig- 
uration cannot be automatically triggered. Dynamic Wright 
supports only foreseen reconfiguration by defining the spe- 
cial behaviour of a configuration. 

The four ADLs do not address the issue of consistent recon- 
figuration (reconfiguration at type and instance levels) as 
shown the Tab. [21 7T-ADL and ACME provides operations 
for both levels, however the two ADLs use external help to 
specify reconfiguration at the type level. C2SADL AML pro- 
vides operations to modify instances. In spite of the toolset 
provides the services for both levels. Dynamic Wright does 
not provide operations to specify dynamic reconfiguration 
for the type of architectural elements. 

The support for specifying the behaviour of the architectural 
elements can be subdivided in two categories: nominally and 
dynamic reconfiguration. Nominally is a set of functions 
that the architectural elements can invoke. Dynamic recon- 
figuration is the specification of a behaviour to compose a 
foreseen dynamic reconfiguration. The ADLs support for 
both is resumed in Tab. [3] 7T-ADL supports both in the 
architectural element behaviour. ACME/Plastik nominally 
behaviour can be considered in two ways: a property of 
architectural element described with an external language, 
e.g. CSP; and, port/rule communication for components 
and connectors; for dynamic reconfiguration, ACME/Plas- 
tik provides the on-do clause. Dynamic Wright glue and 





Type 


Instance 


tt-ADL 


ADL statements with 
external help 


ADL statements 


ACME 
Plastik 


ACME/Plastik state- 
ments with external 
help 


ACME/Plastik state- 
ments 


C2SADL 


not provided by the 
ADL 


operations defined in 
AML 


Dynamic 
Wright 


not provided by the 
ADL 


operations defined in 
an extension of the 
ADL 


Table 3: ADL support for behaviour specification. 




Nominally 


Dynamic reconfigura- 
tion 


tt-ADL 


All architectural ele- 
ments with 7T-ADL be- 
haviour. 


tangled with nomi- 
nally behaviour. 


ACME 
Plastik 


External language 
used in properties 
of the architectural 
elements. 


ACME/Plastik on-do 
statement. 


C2SADL 


Component behaviour 
based on event com- 
munication. 


Not provided. 


Dynamic 
Wright 


Variant of CSP in con- 
nector glue and com- 
ponent computation. 


Configuration special 
behaviour with variant 
of CSP. 



computation clauses define the nominally behaviour of con- 
nectors and components; a configuration has a special be- 
haviour for dynamic reconfiguration. C2SADL has no be- 
haviour for dynamic reconfiguration but nominally compo- 
nent behaviour is described by events communication. 

None of the four ADLs has a mechanism for assessing the 
system. 7T-ADL can rely on 7T-AAL for defining and analyz- 
ing the architectural constraints and non-functional prop- 
erties. While ACME/Plastik has Armani, even though it 
has no formal semantics, and therefore, it is not liable to 
rigorous analysis |33| . C2SADL provides type verification 
for events communication. Dynamic Wright provides a re- 
fined mechanism of control events to determine the moment 
to perform a dynamic reconfiguration. Although, the as- 
sessment of dynamic reconfiguration is not provided on four 
ADLs. 

6. CONCLUSION 

In this paper we analysed the support of ADLs for handling 
dynamic reconfigurations. We started with a motivation ex- 
ample and some reconfiguration scenarios and we described 
the example and the scenarios using four well-known ADLS. 
We used the example and the specifications to discuss the 
following issues: (i) how each ADL addresses the issue of 
consistently reconfiguring both instances and types; (ii) how 
each ADL takes into account the behaviour of the architec- 
tural elements during reconfiguration; and (iii) how each 
ADL supports the assessing of dynamic reconfiguration. 



In comparison to related works, we analysed some important 
issues for the dynamic reconfiguration support at the ar- 
chitectural level: foreseen and unforeseen changes; instance 
and type level modifications; structure and behaviour for all 
architectural elements; definition of nominally and dynamic 
reconfiguration behaviour for all architectural elements; and, 
the analysis of dynamic reconfiguration. 

We can conclude that some issues still remain open as no 
ADL provides support for all of them together: how to apply 
the changes made in type level to their respective instances? 
how to control the set of intermediate states of a software 
system during a dynamic reconfiguration? how to assess 
dynamic reconfiguration? 
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